Floppyshop 2

home *** CD-ROM | disk | FTP | other *** search

/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0107 / gem.txt < prev next >

Wrap

Text File | 1997-04-16 | 128KB | 3,005 lines

==================================================================== (C) 1990 by Atari Corporation, GEnie, and the Atari RoundTables. May be reprinted only with this notice intact. The Atari RoundTables on GEnie are the *official* information services of the Atari Corporation. To sign up for GEnie service, call (with modem in HALF DUPLEX) 800-638-8369. Upon connection, type HHH Wait for the U#= prompt. Type XJM11877,GENIE and hit RETURN. The system will now prompt you for your information. ==================================================================== ************ Topic 12 Wed Aug 27, 1986 S.FERNANDEZ at 21:58 EDT Sub: Questions about GEM This topic will serve to answer questions about GEM be it in programming or ussage. 193 message(s) total. ************ ------------ Category 3, Topic 12 Message 1 Fri May 26, 1989 B.DENHEYER1 [brian d] at 19:24 EDT I have a question about the use of the user-defined GEM objects. I have created a tree with user defined objects that incorporates my own objects which VDI draws for me. What I would like to know is what exactly happens with the parameter which is suppoedly passed to the routine ? In the MWC bindings it is ub_parm. I can't seem to get a hold of it, and it would be very useful for me if the custom routine could be passed a parameter. Any help or information on this subject will be greatly appreciated ! Brian Denheyer ------------ Category 3, Topic 12 Message 2 Fri May 26, 1989 C.DAYMON at 19:41 EDT Brian, I have created a few custom objects myself and there is information passed to the routine. I think it is a pointer to a 'parameter' block. The best source of info I found on these routines was in Tim Oren's "Professional GEM" series which you can find in the library. I think it consists of about 3 good sized archives, but is well worth the download. If I get a chance to look up the routines, I'll post the info. -Craig W. Daymon ------------ Category 3, Topic 12 Message 3 Fri May 26, 1989 A.HAMILTON1 [Alan H.] at 23:17 MDT When a user-defined object routine is called, it's passed a PARMBLK pointer. PARMBLK, defined in object.h, contains as one of its members pb_parm. When the routine is called, ub_parm is copied into it. / / * / Alan * * ------------ Category 3, Topic 12 Message 4 Fri Jun 02, 1989 B.DENHEYER1 [brian d] at 00:44 EDT Thanks you both for the information. I will indeed download the Professional GEM series as soon ass I find it. This place is great ! My questions always get answered ! Now if I could answer questions for someone else. Thanks again, I'm off to GEM land. Brian Denheyer ------------ Category 3, Topic 12 Message 5 Mon Jun 19, 1989 T.HALLIWELL at 23:21 PDT Help please!! I have just formatted my sh204 into 4 5meg partitions and installed timeworks word processor on one of the partitions. I am being told that I have run out of GEM windows to open. Does anyone have a clue as to what is going on. I have been using the hard disk for two years with other word processors and no problem. Thanks for any help. Terry. ------------ Category 3, Topic 12 Message 6 Tue Jun 20, 1989 STACE [Mark] at 02:32 EDT T.Halliwell, GEM only support a max of four (4) open windows at any given time. Before you load Word Writer, try closing some of the unused windows at the desktop. Mark ------------ Category 3, Topic 12 Message 7 Tue Jun 20, 1989 DANSCOTT [Atari Corp.] at 18:26 EDT No, GEM supports up to 8 (eight!) windows at a time, but the desktop can only handle 4 open at a time. This is due to the fact that the desktop must count on an ACC program opening a window of its own if the user calls on it. I don't know how many windows timeworks wants to open, but it must be more than one. Try closing any ACC that may be active (they should be good little ACC's and close themselves upon getting the message from the AES to do so, but....) or that 4th desktop window if you have it open. Dan ------------ Category 3, Topic 12 Message 8 Tue Jun 20, 1989 C.F.JOHNSON at 17:56 PDT Dan, Actually, accessories have very little choice in the matter. When someone runs a program, any open accessories have their windows closed _for them_ by the system. The AC_CLOSE message is saying "Hey, you. I just closed your window." NOT "Hey, would you please close your window?" The problem must be caused by something else, Terry. Sorry, I don't have any helpful suggestions...except to try the obvious, and boot without ANY AUTO folder programs and accessories and see if the same thing continues to happen. - Charles ------------ Category 3, Topic 12 Message 9 Tue Jun 20, 1989 TIMPURVES at 23:29 EDT It really pisses me off that GEM shuts down the ACC's just because I deside to load an application. Would be much nicer is it only shut them down on a TOS/TTP launch. In fact i wrote a "shell" that did just that.. The problem was that a lot of well know apps _assumed_ that the first window they opened was WINDOW ZERO!!!! Talk about morons! ------------ Category 3, Topic 12 Message 10 Thu Jun 22, 1989 TOWNS at 02:17 EDT Yep.. exactly. They are counting on things that might not be true. Also, when you do an appl_exit() call from an application it also sends the AC_CLOSE message to any open desk accessories. -- John ------------ Category 3, Topic 12 Message 11 Fri Jun 23, 1989 JLS [John STanley] at 02:11 CDT Charles, my understanding is that the windows are closed when you return to the desktop, not when a program is run. This means that running from a shell, if your accessory doesn't close its own windows you may run out of window handles. The accessory should close and free -everything- it has requested use of (files, windows, & memory) when it receives an AC_CLOSE message. The fact that many don't and manage to avoid screwing up is only because the desktop is doing illegal things to insure the resources get taken care of. Mind you, I'm not an accessory expert, this is just the impression I've gotten from all the problems I've had to deal with in writing command shells that allow using accessories. If Allan, Ken, or John Townsend are around, I'd appreceate any clarification on this that they can provide. John STanley ------------ Category 3, Topic 12 Message 12 Sat Jun 24, 1989 T.HALLIWELL at 17:55 PDT Thanks everybody for the suggestions and comments on my problem about the windows. I finally figured it out. I had made some adjustments in my desktop.inf and I left an @ at the beginning of my W and not at the end. I had a devil of a time as I couldn't get into my hard disk to get at my desktop.inf on my hard disk. I finally ran ahdi outside of the auto folder, and was able to access my hard disk without using the desktop.inf on my hard disk. I hope this is clear... or rather I hope one of you understands what I just said, in case someone else has a similar problem. Thanks again for the assistance and support. Terry. ------------ Category 3, Topic 12 Message 13 Mon Jun 26, 1989 S.JOHNS at 07:37 EDT Why would it be necessary for accessories to relinquish their memory on an AC_CLOSE? I thought that the whole point was for accessories to reserve all the memory they would ever need at initialization, and then never to ask for more. If you punted your memory on receipt of an AC_CLOSE then you would have to ask for it back again, or else be dead for good. I've got accessories that will all run with their own window on the screen simultaneously (top window active) and then all shut down gracefully and then revive later when a .PRG comes along to "clean house". The accessories all hold on to their memory and everything seems to work fine. Comments? ------------ Category 3, Topic 12 Message 14 Mon Jun 26, 1989 JLS [John STanley] at 22:37 CDT S.JOHNS, sorry if I was unclear. The comments I made about how ACCs should always free all resources allocated to them when they receive the AC_CLOSE message applies only to resources that are requested when the acc is called via the menubar. The specific thing that triggered my comment was someone talking about how they thought they shoudn't free their window handles when shutting down (which is wrong and causes many problems...). when those accessories are run from a shell program (that can't pull the illegal tricks to clean up that the desktop can...) ------------ Category 3, Topic 12 Message 15 Thu Jun 29, 1989 S.JOHNS at 07:17 EDT Do you mean, in other words, that if an accessory grabs memory at the time of its menubar invokation (which is what I understand it really shouldn't do) THEN it should free that memory on AC_CLOSE? If so, I agree. But, I've been told that to ask for memory at any time after initialization is asking for trouble. Others must know more about this than I do, but I avoid it on a tip and seem to have no problems. ------------ Category 3, Topic 12 Message 16 Thu Jun 29, 1989 C.F.JOHNSON at 08:30 PDT S.Johns, An accessory can safely grab memory at its startup time. And there is a technique that allows an accessory to allocate memory at other times too; although this technique will occasionally result in unavoidable memory fragmentation. The problem with accessories and Malloc is due to the fact that the system keeps a pointer to the basepage of the current application. Whenever a Malloc call comes through, the system assigns that allocated memory to the basepage of the current app. If an accessory does this while the GEM desktop is the current app, there won't be a problem because it's not possible to exit from the desktop. But when another application terminates, the system methodically frees up all allocated blocks assigned to its basepage. And since, when you open an accessory, the basepage pointer does NOT point to the acc's basepage, that means that any memory allocated while the accessory was active gets assigned to the current app, not to the acc. Hence, it gets freed along with everything else when the application terminates. The simple solution is to change the basepage pointer to point to the accessory's basepage when it needs to allocate memory, and replace the pointer after Malloc'ing. The Mega ROMs and TOS 1.4 now have a legal way to find this pointer...it's in the OS header at the beginning of ROM. For TOS 1.0, you'd have to use a hard address (which is OK, since it won't change). - Charles ------------ Category 3, Topic 12 Message 17 Fri Jun 30, 1989 JLS [John STanley] at 02:06 CDT S.JOHNS> Yes, that's exactly what I mean.... ------------ Category 3, Topic 12 Message 18 Sun Jul 30, 1989 J.H.CARROLL at 13:20 EDT Here's a short question : I just downloaded "PACKER" from the libraries... What is this program doing so that it can reduce the size of an executable program file by 50% ? Jon ------------ Category 3, Topic 12 Message 19 Tue Aug 01, 1989 W.V.FISHER at 20:33 CDT Jon - That is the question I wanted to ask! What is being compressed? ------------ Category 3, Topic 12 Message 20 Tue Aug 08, 1989 N.DAVIS1 at 20:50 EDT I have include raster images in forms by using a user-defined object which just calls some code, does a vroom-copy, and no problem. Why doesn't this work with a new desktop form? thanks, Neil ------------ Category 3, Topic 12 Message 21 Tue Aug 08, 1989 GRIBNIF at 21:32 EDT What happens when it doesn't work? Does it crash or just not do anything? If the latter is the case, then I might check the clipping rectangle to see that it is being set correctly. I had noticed that making an AES call during the drawing of the desktop user-defined object definitely causes a crash (because you are effectively calling the AES from within an AES call, which is a no-no) but doing a VDI call to blit something should work. If not, then you'll have to go to Line A. Dan ------------ Category 3, Topic 12 Message 22 Fri Aug 18, 1989 JLS [John STanley] at 05:25 CDT BTW, I still haven't seen an "official" response relating to my comments/questions in message #11. Do the folks at Atari read this topic? On an entirely different subject: I'm writing code to display a desktop- style screen just before invoking a GEM program via a Pexec call. I've got the code working to fill all but the top of the screen with the background color/gray. What I'm looking for is a code snippit that will draw the "blank menubar with filename in it" at the top of the screen. I'm trying to avoid having to use a resource with this so I want to avoid directly using anything that requires a resource. Suggestions anyone? ------------ Category 3, Topic 12 Message 23 Fri Aug 18, 1989 DARLAH [RT~SYSOP] at 08:16 EDT I will make John aware of this topic if he does not. ------------ Category 3, Topic 12 Message 24 Fri Aug 18, 1989 TOWNS at 15:41 EDT I am not sure on this. but here is what I believe to be true: 1. The desktop will internally close any windows and send AC_CLOSE messages to ANY open desk accessories. It's the responsibility of the desk accessory to respond to the AC_CLOSE message. Please note: The desktop doesn't actually show you closing the windows on the desktop, it does it internally. This means that you will never see the desktop physically close windows. 2. On an appl_exit() call.. The AES will close ANY open windows and send AC_CLOSE messages to any open desk accessories. Please note: It's bad programming practice to rely on the AES to close your windows for you. You should close them yourself before calling an appl_exit() at the end of your program. As for the other questions regarding the freeing on malloced memory for desk accessories and AC_CLOSE, I will get back to you.. -- John ------------ Category 3, Topic 12 Message 25 Mon Aug 21, 1989 C.F.JOHNSON at 10:56 PDT John, What about the problems with desk accessories that take over system vectors, when you change resolutions from the desktop? I really wish something had been done about this in TOS 1.4... it's a glaring shortcoming. (For anyone who doesn't know what I'm referring to....the desktop frees up all the desk accessories on a res change, but _doesn't_ tell them about it! So if any accessory has installed itself in interrupts or trap vectors, it will almost certainly cause a crash on a res change. The only solution [which I used in MultiDesk] is to use a complicated, kludgy, undocumented [although not strictly 'illegal'] method. I would dearly love for Atari to either have the desktop replace all interrupt and trap vectors on a res change, or failing that, to at _least_ document a method by which accessories can take care of the problem themselves.) - Charles ------------ Category 3, Topic 12 Message 26 Mon Aug 21, 1989 GRIBNIF at 20:19 EDT If the desktop were to replace all the trap vectors on a resolution change, then it would also have to reload everything from the AUTO folder (since this is more often the source of trap interception). Of course, some AUTO folder programs depend on GEM not being present at all, since it normally isn't when they are run. So, if you could basically force the rez change, punt the AES, reload the AUTO folder, and then re-initialize GEM in the correct rez (ignoring the one in DESKTOP.INF, of course) then all would be well. Have fun, Ken! <smile> Dan ------------ Category 3, Topic 12 Message 27 Mon Aug 21, 1989 C.F.JOHNSON at 19:00 PDT But by the time the desktop application is up and running, the AUTO folder programs have already been installed. It wouldn't be necessary to reload the AUTO stuff at all; all the desktop would need to do would be to take a 'snapshot' of the vectors at the time it runs, and replace them on a res change. The AUTO programs could remain in memory without any problems, since the desktop would be restoring the vectors to the state they were in _after_ the AUTO folder. - Charles ------------ Category 3, Topic 12 Message 28 Wed Aug 23, 1989 JLS [John STanley] at 01:18 CDT I just wish the accessories would be told about a rez change via the normal GEM message method. A well written accessory shoudln't have any trouble "adapting" to a new resolution if there was a standard for it. Reloading the accessorys is a kludge that shouldn't ever have been retained past TOS 1.0. Having to "semi-reboot" just to change resolutions is a throw-back to the 8- bit style game programs where you had to reboot the machine to exit some programs. This is something that has no place in a "professional" computer system. John <this is a major irritant, or had you guessed?> Stanley ------------ Category 3, Topic 12 Message 29 Wed Aug 23, 1989 C.F.JOHNSON at 09:36 PDT I agree 100%, John. The problem with desk accessories and changing resolutions is a tremendous hassle. Personally, I don't care _what_ method Atari uses to solve it, as long as they do something. Document a method that accs can use, at the very least - it's too late to fix the problem in TOS 1.4, but I would think that, with the source code for TOS in hand, it wouldn't be too difficult to say to developers, "OK, do this, this, and this, and you'll survive a res change." Come on, Atari....talk to us. - Charles ------------ Category 3, Topic 12 Message 30 Wed Aug 23, 1989 TOWNS at 15:12 EDT HAve you guys thought about talking to someone from Atari about this? This area is not read by most of the Atari people and I can't do anything about this problem. Try contacting ATARIDEV (J. Patton) or K.BAD. ------------ Category 3, Topic 12 Message 31 Thu Aug 24, 1989 GRIBNIF at 00:31 EDT Actually, John, I don't know about a message being passed as the best method. Some desk accessories use different resource files for different resolutions and a desk accessory would either have to live with having the wrong one in memory or, if GEM cleared it out on the rez change (which, in itself, would probably create memory fragmentation because all the DA's are left in memory when the RSC's aren't) it would always have to reload the RSC, even if there wasn't a different one for the new resolution. Dan ------------ Category 3, Topic 12 Message 32 Thu Aug 24, 1989 TOWNS at 17:21 EDT A quick question.. why does it make a different if desk accessories and reloaded on a resolution change? ------------ Category 3, Topic 12 Message 33 Thu Aug 24, 1989 C.F.JOHNSON at 20:42 PDT John, It doesn't really make a difference if accessories are reloaded on a res change...._unless_ one of the accessories has grabbed any interrupt or trap vectors. On a res change, the accessories are freed, but they are not told about it. Consequently, when memory is cleared (when the first acc loads after the res change) these nice interrupt vectors are suddenly pointing at lovely zeroes, and the result is a system crash. In my opinion, the best way for the system to handle this would be to take a 'snapshot' of all pertinent vectors when the desktop first runs, and then replace this snapshot before freeing the accessories and performing the res change. A new "message" for accessories would not really solve the problem, unless it was guaranteed that the accs would get this message in the exact reverse order that they grabbed their vectors....which is impossible with the current ST event management system. - Charles ------------ Category 3, Topic 12 Message 34 Fri Aug 25, 1989 K.BAD [S/W Engine] at 04:21 EDT Okay, John Townsend has heard me say this before again and again, I guess it's time for me to say it here. Now, everybody repeat after me: A DESK ACCESSORY IS NOT A PROCESS. A DESK ACCESSORY IS NOT A PROCESS. A DESK ACCESSORY IS NOT A PROCESS. There, now that I've got that off my chest, let me get on with the topic at hand. Because, as we all know, a desk accessory is not a process, it does not have all the facilities available to it that processes do. Notably, it can not expect to keep files open and survive, and it can not Malloc memory from the system and expect that memory to always be available to it, and it should not intercept vectors that will cause problems later! I really hesitate to say all this, because the folks involved in this discussion here have "stretched" the definition of a desk accessory way beyond the original intent. A desk accessory should be, hmm... maybe Webster can help me on this one: ac-ces-so-ry n, a: a thing of secondary or subordinate importance : ADJUNCT b: an object or device not essential in itself but adding to the beauty, convenience, or effectiveness of something else What you seem to want is for desk accessories to be processes in their own right, and that just ain't the case. The solution, although it may seem inconvenient for users, is to team accessories with terminate and stay resident utilities so that you get the best of both worlds. The accessory becomes the front end of the utility that hangs out in memory, cleanly survives resolution changes, etc. The accessory adds to the beauty and convenience of the TSR. And anyone who complains about the AES effectively having to reboot on a resolution change is welcome to write a new AES that does not require that. Or you can send your resume to 1196 Borregas to the attention of Leonard Tramiel, with a note explaining that you would like to take over AES revision from Ken Badertscher. I would like nothing more ;-) TRUST ME when I say that it is NOT as easy as it sounds... ttfn... (*ken @ atari*) ------------ Category 3, Topic 12 Message 35 Fri Aug 25, 1989 K.BAD [S/W Engine] at 04:27 EDT One other thing... John is right - I don't get up here very often and when I do, it's "recreation time" ;-) My job is mostly concerned with system software development, not support, it's just that I'm a masochist and like to get online and take punishment. If you have serious problems or concerns, please raise them with the developer support folks at Atari, and/or leave a message in the ATARIDEV conference here on GEnie, that's what it's here for. Thanks for your consideration... (*ken @ atari*) ------------ Category 3, Topic 12 Message 36 Fri Aug 25, 1989 JLS [John STanley] at 06:19 CDT Ken, I know what you're saying, but your last msg could -easily- be read as "pay Atari for developer access to GEnie or leave me alone..."... Users of the ST/MEGA and non-"Atari developer" programmers shouldn't have their comments and concerns ignored just because they don't put their comments in the "right place" which people have to pay a significant ammount of money to access... ------------ Category 3, Topic 12 Message 37 Fri Aug 25, 1989 DARLAH [RT~SYSOP] at 08:49 EDT I have to admit, I have enjoyed the conversation in this area. I would hate to limit those that did not pay their $$. Those that have can get priviliged info but what is going on here should not be in that classification. <------ Just my 2 cents but I feel strongly on this one. Anyone ever noticed how much Category 3 has grown?? ------------ Category 3, Topic 12 Message 38 Fri Aug 25, 1989 D.FLORY [ALERT-syscop] at 15:02 EDT John, and anyone, if you want to get info to the people on the Developer area just send E-mail to TOWNS, ATARIDEV or K.BAD. John is the SYSOP there, ATARIDEV is J.Patton of developer support and we all know who the harried K.BAD is. ------------ Category 3, Topic 12 Message 39 Fri Aug 25, 1989 DARLAH [RT~SYSOP] at 18:47 EDT You can also leave message in the developers area if you are a registered developer. ------------ Category 3, Topic 12 Message 40 Fri Aug 25, 1989 C.F.JOHNSON at 16:34 PDT Ken, If you can tell me the page number in the Developer's Kit documentation where it says that desk accessories should not intercept vectors, I'd be very surprised. I've read all of that stuff from cover to cover, and I honestly don't remember seeing anything like that. Yes, I know about the problems with file handles and with Mallocs from accessories, but interrupt vectors? This is news to me. Frankly, something like MultiDesk would be _extremely_ difficult to implement with a TSR program/desk accessory combination. But if there were some official word from Atari saying, "This is the way it should be done" when I started working on it, that's what I would have done. (Probably.) It seems to me that it's a little late to be trying to put this particular cat back in the bag, when some of the most popular utilities for the ST are in the form of desk accessories that take over interrupt vectors. The purpose of this whole discussion (at least _my_ purpose anyway) is to try to find a way that "pseudo-processes" like desk accessories can somehow legally survive a resolution change. Most professional developers have worked out some sort of scheme for doing this, but none of them are totally reliable. And the hackers and hobbyists are more in need of information like this than anyone. Most of the tech support calls we get relate to this or that public domain/shareware program that always ends up doing something really dumb; but you know, I can't blame people for trying some of this stuff when I realize that most of the time, they're operating in a complete vacuum, as far as hard info about handling interrupts and trap vectors goes. - Charles ------------ Category 3, Topic 12 Message 41 Sat Aug 26, 1989 K.BAD [S/W Engine] at 00:14 EDT John S. & Darlah: TANSTAAFL. (There Ain't No Such Thing As A Free Lunch.) I agree with you in spirit, though, that's why I log in here in the "free support" category and answer questions! I apologise if my response seemed a bit knee-jerky, but I've been getting quite a bit of flak lately (not all of it from here) for the fact that Atari doesn't provide support freely to all. For my part, though, I'll do my best to continue to ladel out the soup here in the soup kitchen of programming information. But the people that want an all- you-can-eat brunch are encouraged to dress up and head on out to the nicer dining establishments. But don't expect Duck L'Orange for a dime... Charles: You have struck to the heart of the problem. There ISN'T anywhere in the documentation that discusses what DA's should and should not do. There's precious little discussion of what DA's are in the first place! I am reminded, though, of the old joke: Patient: "Doc, it hurts when I do this!" Doctor: "Well, then don't do that!" In message #34 I didn't say that DA's shouldn't take vectors, I said that they shouldn't take vectors which would cause problems later. That's just common sense. But you're looking for a way for DA's to communicate more easily with TSR's... Here's an idea (completely off the top of my head, and I have NO idea how well it would work in implementation, but...): Make the DA a front end only. Have all the vector-grabbing "guts" of the application live in the TSR. When the DA is first loaded (or reloaded on a res change) have it communicate to the TSR that it's time to grab vectors again, or do whatever else is needed because the AES has yanked the floor out from under the DA. Implement some kind of message passing (via trap calls, shared memory, whatever) that enables the DA to transfer control to the TSR code at the appropriate times. Recently, we have come up with something called the "cookie jar" which should help a situation like this IMMENSELY. As soon as I have leave to do so, I'll post the cookie jar specification PUBLICLY so that everyone can see how it works. Basically it is a system-level supported means for TSR's to register their existence so that other programs can find, via a simple table look up, whether a particular extension or TSR service is available. It's simple, straightforward, and I wish someone had come up with it years ago, because it would have solved a LOT of compatibility problems that have cropped up in the TSR arena (for example, the Diablo emulator's less-than-ideal method for determining whether or not it was installed). Forgive the length of this message... I hope we can come up with some solid solutions, though! ttfn... (*ken @ atari*) ------------ Category 3, Topic 12 Message 42 Fri Aug 25, 1989 C.F.JOHNSON at 22:58 PDT "Cookie jar," eh? Now that's the kind of thing I've been talking about. I guess I'll have to wait for more details about it, but that sounds a damn sight better than what we had before, which is nada, nil, zilch, a free-for- all. (Actually, that should read "what we have now" above.) Thanks for the response; if I was starting to sound a little frustrated there, it's because I _have_ talked to various people at Atari about this res change problem several times over the course of the last three years, with no result. - Charles ------------ Category 3, Topic 12 Message 43 Sat Aug 26, 1989 DOUG.W at 07:09 EDT I'm currently using a scheme similar to what Ken suggests, and have an AUTO program which intercepts the vectors (in my case, TRAP #13 & #14), and an ACC which makes certain TRAP #13 or #14 calls which my interceptor picks up and handles as appropriate. The only thing you have to be careful of is that your "key" TRAPs are unique. I am using legal call with illegal (but specific) parameters, such as a buffer address of $100, which will obviously cause an error if the AUTO program hadn't been run, but which the AUTO program can easily recognize and deal with. --Doug ------------ Category 3, Topic 12 Message 44 Sat Aug 26, 1989 C.F.JOHNSON at 10:17 PDT Unfortunately, there are several aspects of MultiDesk's operation that make it _extremely_ difficult to code in this way. (As I said before...and being any more specific would reveal trade secrets.) It wouldn't be impossible, but at this point in it's development (we're at version 1.82), I'm not very open to the idea of a radical restructuring like that. The other point that should be made is that this TSR/ACC approach makes things exactly _twice_ as complicated as before for the user. (Not to mention how it complicates the programmer's job, maintaining and updating two separate programs.) Yes, it is an idea, and it's a way to circumvent the res change problems with accs .... but it's _far_ from ideal, in my opinion. - Charles ------------ Category 3, Topic 12 Message 45 Sun Aug 27, 1989 K.BAD [S/W Engine] at 03:50 EDT Charles, believe me, I know *exactly* what you mean when you talk about radical restructuring being a major pain. The way the AES is put together would make it incredibly difficult to pull off a res change without rebooting the AES. Res dependencies are not encapsulated in any way. They're scattered all over the code, and it would take a long time (development wise) to rat them all out. I agree, the TSR/DA approach is not ideal, but I've used it successfully in a couple of applications I wrote for my own use, so I know it can be done without too much difficulty (if you start with that approach in mind!). The problem with other methods that have been discussed here (having the AES send a unique message at res change time) is that they won't work in existing ST's, and we're trying to come up with a solution that will work now, n'est ce pas? I'm open to suggestinos... ttfn... (*ken @ atari*) ------------ Category 3, Topic 12 Message 46 Tue Aug 29, 1989 JLS [John STanley] at 20:02 CDT Ken, first off, thanks for the support you have been giving out soup-kitchen style. I'm a registered developer, but I firmly believe that Atari's best interests (and mine) are served when more programmers (developer and non) know more about "the right way" to do STuff. About the "Cookie Jar". I'll be looking forward to seeing more on this soon. One thing I've considered that this may be able to help with (if it's not cast in stone yet) is allowing TSR's to share info about who's resident, what resources (hotkeys, interrupt vectors and subfunctions) are being used to avoid or deal with possible conflicts. Is this out in left field, or will the CJ be able to help with this? Last, on the rez-change acc vector-intercept (RAVI?) problem. If, along with all the other vectors an accessory traps, it also traps the vector at $46e (swv_vec in "Internals"), the accessory will be able to momentarily gain control just before the reset takes place. When the system jumps thru this vector, the rez-change code in the accessory can replace the original vectors which will effectively un-install the accessory from that trap. As long as the original hooking of the vectors takes place with no gem calls interspersed, this should unstack the accessories in the same order they were installed in. When finished un-instaling, then the rez-change code just jumps thru the original swv_vec pointer to the next routine in the chain and finaly to the system reset vector... I came up with this idea when I first heard about accessories being installed on vectors, but I haven't done that much with accessories (TSR's are easier for me :^) and kept wondering why people didn't use this method to prevent accessories from crashing the system on a rez change if they install themselves on permanent vectors... I've yet to hear anyone mention this method and don't know why... This avoids the problems with the dual TSR/DA and the only possible problem is if the user loaded a TSR program from the desktop or a shell. If that happend, the accessory would have to unhook the late-loading TSR from the vector to avoid a crash and it would be up to the user to reload the TSR again after the rez-change... Anyone see any problems with this method? ------------ Category 3, Topic 12 Message 47 Tue Aug 29, 1989 C.F.JOHNSON at 18:19 PDT John, There's just one problem with using the vector at $46E to catch a resolution change from the desktop...it doesn't work. That's one of the first things I tried. (Always go with the documented stuff first...) If that vector _were_ actually used during a resolution change from the desktop, it would work just fine...but noooo. - Charles ------------ Category 3, Topic 12 Message 48 Tue Aug 29, 1989 JLS [John STanley] at 22:11 CDT Oh... I see now, thanks Charles. The $46e vector is only used on monitor-change, not on all resolution changes... <sigh> ... Back to the drawing board. What method does the desktop use to trigger the reset for the resolution change? (If it's YAIDT (yet another illegal desktop-only trick) I'm probably going to scream...) <But, why stop now>...? ;^) Ken, desktop internals question. I've got a hunch that the desktop punches the new res value into the word at $44a and then does some black magic to trigger the accessory+GEM special reset. Is there -any- system call between the point when the new value is placed there and when the psudo-reset takes place? Something that could be used to monitor for a new value? ------------ Category 3, Topic 12 Message 49 Wed Aug 30, 1989 GRIBNIF at 21:24 EDT John, Just because only the desktop can do it, it's not illegal <smile>. Dan ------------ Category 3, Topic 12 Message 50 Fri Sep 01, 1989 K.BAD at 01:38 EDT Why do you people keep insisting that the Desktop is not part of the system? Why, why, why??? I can understand you wishing that it wasn't (especially Gribnif ;-) but it just isn't the case! The desktop is an integral part of the AES, in all of the current TOS implementations. The resolution change that takes place when the user selects a different resolution from the Set Preferences dialog is yet another example proving this. The desktop shares a variable with the AES, telling the AES whether or not it's time to reboot the AES and change resolution. And no, Atari can't publish that address, because it is different in each and every TOS ROM version. I looked for a special routine which might be used to signal a res change to a desk accessory, but couldn't find one in a quick glance at the boot/reschange sequence. Here is an oversimplified pseudo-C version of the AES/desktop: aes_desktop() { for(;;) { initialize(); load_accessories(); if( first_boot && autoboot_app_exists ) shel_write( autoboot_app ); aes_shell(); free_accessories(); } } aes_shell() { do { if( something_shel_written ) run_program(); else desktop(); } while (!res_change); } Maybe, if you were hooking traps, you could hook trap 1 and look for an Mfree call with your basepage as the argument? I don't know. I much prefer the TSR/DA combo, since it's cleaner and more flexible. ttfn... (*ken @ atari*) ------------ Category 3, Topic 12 Message 51 Sun Sep 03, 1989 PSINC at 11:06 EDT I'll add my two cents worth. Being a primarily hardware developer, I'm unbiased<grin>. Ken is right, DA's shouldn't do anything that will "cause problems later". However, since Atari has done very little to tell us what's naughty and what's nice regarding DA's, I can't see how we are supposed to know what will "cause problems later". We don't have a real good guide book to go by (ala "Inside Macintosh' etc.). Therefore, I think that since it's Atari's responsibility to make the developers aware of what is correct and what isn't regarding programming, if Atari fails to do so they should do all they can to help the developers make the existing programs compatible (Charles idea) and not simply say "ah, you probably shouldn't have done that" after someone has coded a program for a year! Hmm, that was the my longest sentence ever! Mark ------------ Category 3, Topic 12 Message 52 Sun Sep 03, 1989 C.F.JOHNSON at 09:48 PDT Mark, Amen! That's my point exactly. All of a sudden, we're being told that DAs shouldn't do things (like steal vectors) that will "cause problems later". I've been a registered developer for _years_ and this is the first time I've heard this policy...if simple guidelines had been laid out in the developer's documentation a long time ago, the problems with desk accessories and res changes would not exist today. I sincerely doubt that any user is going to want to give up Turbo ST, or MultiDesk, or Thunder, or any of the myriad other DAs that take over interrupt/trap vectors. I know I wouldn't. And it's a bit much to expect the developers of these programs to go back and start from scratch again, with the TSR/ACC combination that Ken suggested. I have absolutely no plans to do this with MultiDesk -- I've got much more important things to do with my time. Ken, What about my idea of a "vector snapshot" TSR program that saves all the important stuff at exec_os time? I'd be happy to write a program like this, if I had a foolproof documented way to detect a resolution change. (I left a message to this effect before, but I think it got wiped out in the GEnie crash.) The "snapshot" approach is the only reliable way to solve this problem, as far as I can see. - Charles ------------ Category 3, Topic 12 Message 53 Mon Sep 04, 1989 K.BAD [s/w engine] at 04:50 EDT Detecting the resolution change is still the problem, Charles. Have you tried making the DA watch for an Mfree with its own basepage as the argument? As far as I know, the only time the DA's TPA should be freed is by the AES on a resolution change. If you see the Mfree call, unhook all your vectors, then let the Mfree fall through. Lemme know how that works... ttfn... (*ken*) ------------ Category 3, Topic 12 Message 54 Mon Sep 04, 1989 C.F.JOHNSON at 09:53 PDT Ken, I'll try that approach; sounds like it might be possible. Thanks for the suggestion. - Charles ------------ Category 3, Topic 12 Message 55 Tue Sep 05, 1989 PSINC at 10:43 EDT Yep Charles, since Atari didn't make any guidelines to start with I think they should help to solve the problem with the knowledge they have on the AES. I don't think making rules up midstream is the answer. To be honest, at first I thought ' I bet Apple wouldn't let Mac devs steal vectors in this way", but then I thought "wait a minute - they have stated what is correct, and what isn't, from the beginning.". All of us agree that we have to follow the rules. But we have to know what they are! Mark ------------ Category 3, Topic 12 Message 56 Thu Sep 07, 1989 JLS [John STanley] at 19:57 CDT Ken, first off, I haven't seen anyone say anything about not wanting the desktop to be part of the system. What I've seen time and time again, however, is that developers think that anything the system can do should be trappable (is that a word?) and useable thru an applications program. I see no reason that the desktop-style resolution change shouldn't have always been avalable as a legal system call. Nothing you've said has changed my opinion on that. (This is especialy true since you also keep insisting that shell programs, not gemdos are responsible for intercepting and processing shel_write calls. If something that inherent to the proper functioning of interlocked gem programs is a function that an independant shell has to process, then I see no reason to keep any aspect of the desktop from being included in a secondary shell-type program.) Re the ACC+TSR vs ACC question. I agree that the ACC+TSR is -technicaly- simpler. Unfortunately, using that method is more complex for the user. Any time you have more than one file necessary for a program to run correctly, you increase the probability of confusing and frustrating the user by the square of the number of files. Any time I can create a single program that (correctly) accomplishes what my competitor needs two to accomplish, I have an edge and the user will perceive my product as being easier to use. I agree with the others who've essentialy said "Atari should have produced and -freely- distributed guidelines for all these concerns over 5 years ago". Since they haven't, simply saying "you shouldn't have done that" without providing a "legal" alternate method is simply bad business for Atari and isn't playing fair with the developers. ------------ Category 3, Topic 12 Message 57 Fri Sep 08, 1989 SANDY.W at 10:30 EDT I have to agree about the increased confusion that would result from having to keep track of, and possibly modify, two different files. Especially for new users. Some people have enough problem just understand the basic desktop, seriously. The more possibilities you give the computer phobic, the more ways they will find to break things, and incrase the probability they will not try again. ------------ Category 3, Topic 12 Message 58 Tue Sep 26, 1989 J.IRVIN1 at 21:18 PDT I have noticed a problem with TOS 1.0 mouse button response (using evnt_multi()) after calling form_alert(). The response time is usually on the order of 1/100 sec.; after form_alert() it slows to 1/5 sec and can only be fixed by rebooting. TOS 1.4 doesn't have this problem. I wrote a program to benchmark button clicks and uploaded it along with the source (MWC) as file #12259, BTNTIME.ARC (beware of file #12257; it's a botched upload). I figure other people must have tread this same ground long ago, does anyone have a fix for this? Thanks, Jarrell Irvin ------------ Category 3, Topic 12 Message 59 Sat Oct 14, 1989 D.HURSEY at 15:02 PDT Is it possible to get the metafile function bindings and escape codes as well as any changes in old bindings in rainbow tos--without paying for the developer's kit? dvh ------------ Category 3, Topic 12 Message 60 Mon Oct 30, 1989 C.HARVEY at 23:06 EST OK all you GEMophiles, tell me if you've heard of this before: I have programmed a text editor as an accessory (named DIARY), and all was fine until I added some embedded resource stuff (3 simple dialog boxes). Now when I boot up, my acc does not show up in the menu of acc's. However, if I then run any other program, or even SHOW a text file from the desktop, my acc starts showing up in the menu as it's supposed to. I've played around with where I put the menu_register command with no change. The program itself runs fine once you can get to it, and it loads/runs fine from Multi-desk. Craig Harvey (c.harvey) ------------ Category 3, Topic 12 Message 61 Tue Oct 31, 1989 A.HAMILTON1 [Alan H.] at 04:43 MST Perhaps if you uploaded some code fragments, we could see what's going on. Are you making *any* GEM calls before you call menu_register()? If you are, that might cause the problem you describe. / / * / Alan * * ------------ Category 3, Topic 12 Message 62 Tue Oct 31, 1989 E.ROSENQUIST at 09:05 EST Craig: see my reply in the text editor topic (cat 2, topic 37). Eric ------------ Category 3, Topic 12 Message 63 Tue Oct 31, 1989 C.HARVEY at 23:34 EST The only earlier GEM call is the appl_init, which I believe is necessary to get the appl ID for the menu_register call. ------------ Category 3, Topic 12 Message 64 Wed Nov 01, 1989 A.HAMILTON1 [Alan H.] at 04:47 MST Right, you have to do appl_init() before you do any GEM calls. You should have something like this: extern int gl_apid; main() { appl_init(); menu_register(gl_apid, " Title for ACC menu"); /* Other initialization code here */ event = evnt_multi(..... /* Or use evnt_mesag() */ Is this close to what you have? / / * / Alan * * ------------ Category 3, Topic 12 Message 65 Mon Nov 06, 1989 C.HARVEY at 21:18 EST That's it exactly, except in Modula-2 the menu_register call takes a string variable (rather than a constant) so there is a line after the appl_init to assign the menu title to the string variable. ------------ Category 3, Topic 12 Message 66 Wed Nov 15, 1989 D.LEMAY2 [Darby] at 01:04 PST HELP!!!!! I am currently writing a inventory control prg and have come across a problem with displaying dialogs. The dialog is fairly basic: a parent box with a child box containing editable boxes for input. In the parent box are the exit buttons. When I try to display the dialog, only one or two of the buttons or text editable boxes are displayed, not the parent box. I'm using Laser C with the Laser Resource prg. Sometimes just the child box with the editable boxes are displayed. Everything works- the text cursor moves to all the boxes (even the undisplayed ones) and the buttons work (if I can find them on the screen). I have checked the header file, all and have sorted it everyway possible. I have traced the address of the tree to see if has been corrupted-nope. At one time I got it to display properly, but when I added a second dialog box to the rsc file, both wouldn't display properly. Can any body tell me what's happening? I thought this would be an easy part of the program, but so far it has been totally frustrating. I even wrote a little prg to test dialogs- thinking maybe my code was screwing it up- but it still does the same thing. Please reply soon- my forhead is getting sore and holes are appearing in the wall!!! Thanx D.LeMay ------------ Category 3, Topic 12 Message 67 Wed Nov 15, 1989 E.ROSENQUIST [Strata] at 12:59 EST Check the parameters you're passing to objc_draw() - it sounds like the starting object index and/or drawing depth is not correct. You want 0 (or ROOT) for the starting object and MAXDEPTH for the drawing depth. Eric ------------ Category 3, Topic 12 Message 68 Thu Nov 16, 1989 A.HAMILTON1 [Alan H.] at 03:10 MST Also be sure that the clipping rectangle passed to objc_draw() is large enough to contain the entire dialog. Making it the same dimesions as what's passed back from form_center() is what you normally want. / / * / Alan * * ------------ Category 3, Topic 12 Message 69 Wed Nov 22, 1989 D.LEMAY2 [Darby] at 00:39 PST Alan and Eric: Thanx for the reply. The two ideas you have mentioned I have already thoroughly checked. Here is the exact code I'm using: (The example dialogue is a box with one exit button in it) OBJECT *box_addr; int xbox, ybox, wbox, hbox, smally, smallx, smallw, smallh, exit_obj; rsrc_gaddr(0, ABOX, &box_addr); form_center(box_addr, &xbox, &ybox, &wbox, &hbox); smallx = xbox + (wbox/2); smally = ybox + (hbox/2); smallw = 0; smallh = 0; form_dial(FMD_START, smallx, smally, smallw, smallh, xbox, ybox, wbox, hbox); form_dial(FMD_GROW, smallx, smally, smallw, smallh, xbox, ybox, wbox, hbox); objc_draw(box_addr, ABOX, 10, xbox, ybox, wbox, hbox); exit_obj = form_do(box_addr, -1); form_dial(FMD_SHRINK, smallx, smally, smallw, smallh, xbox, ybox, wbox, hbox); form_dial(FMD_FINISH, smallx, smally, smallw, smallh, xbox, ybox, wbox, hbox); box_addr[exit_obj].ob_state = NORMAL; / I cannot find any error in this code. In further experimentation, I have found that the first dialogue created in a rsc file displays fine, but when I add another dialogue, the second one screws up in the manner I have described. Also any others I add don't display properly. I have tryed both LASER CFG.PRG and another called KRESOURC. Same thing happens with both, so I don't think it's a problem with the program Any other ideas? Darwin ------------ Category 3, Topic 12 Message 70 Wed Nov 22, 1989 A.HAMILTON1 [Alan H.] at 05:42 MST The problem is with the objc_draw() call. Change it to read: objc_draw(box_addr, ROOT, MAX_DEPTH, xbox, ybox, wbox, hbox); If your header doesn't define ROOT and MAX_DEPTH, they are 0 and 8 respectively. The second argument to objc_draw() is the number of the object within the tree to start drawing at. Normally, you want to start at the "bottom" part, the root, object #0. You put ABOX, which just indicates where your dialog is in the .RSC file. That's what's making your dialog screw up when you add another to the .RSC file. ABOX changes, making objc_draw() start at a different level. The third parameter indicates how many children of the starting object are to be drawn. Zero will make it draw only the object specified in the second parameter. One through seven will make it draw one to seven levels below the starting object. Eight is a special number that indicates you want to draw all objects below the starting object. Ten, which you put, isn't valid. / / * / Alan * * ------------ Category 3, Topic 12 Message 71 Wed Nov 22, 1989 DOUG.W at 12:11 EST In the Depth field, the value 8 has no significance. Any value greater than the number of levels results in all levels being drawn. I suspect DRI picked 8 as a reasonable, but arbitrary value. --Doug ------------ Category 3, Topic 12 Message 72 Thu Nov 23, 1989 D.LEMAY2 [Darby] at 01:04 PST THANX A WHOLE LOT ALAN!!!!!!! I was going by the example program in the ATARI ST Application Programming book by DATATECH PUB. They don't tell you that information, and since your only working with one dialogue, it works fine. They say use 10 as the depth field to cover most circumstances. I'll check and see if MAX_DEPTH is defined. Well, now I can get on with the program! Sure was frustrating, having such a simple seeming code continually screw up. Thanx again, and thanx for the quick reply!! ***Darwin*** ------------ Category 3, Topic 12 Message 73 Sat Nov 25, 1989 L.WEINHEIMER at 13:30 PST Is it possible, and if so how, to change the text in the menu for a desk accessory, once it has been loaded. Calling the registration a second time does not work, so I was wondering how it might be done. This would be great for DAs to signal status or availability. Larry ------------ Category 3, Topic 12 Message 74 Mon Nov 27, 1989 J.ALLEN27 at 00:12 EST Yah that would be nice. ------------ Category 3, Topic 12 Message 75 Mon Nov 27, 1989 C.DAYMON at 20:00 EST I've noticed several programs that make the desk accessories unavailable when they are running. One is the game, Drachen, from Germany. Is there a GEM call that I don't remember that was used to achieve this? (Actually, I can't think when I would use it, but I'd like to know.) -Craig W. Daymon ------------ Category 3, Topic 12 Message 76 Mon Nov 27, 1989 E.ROSENQUIST [Strata] at 21:08 EST I think that all they do is make the menu entries DISABLED, either by accessing the object in their menu tree directly or by calling menu_ienable(). Eric ------------ Category 3, Topic 12 Message 77 Mon Nov 27, 1989 GRIBNIF at 21:59 EST I doubt that changing the text of the menu entries for DA's could be done legally. I believe that they are part of the resource (in memory) for the GEM desktop, even when another program is running. Dan ------------ Category 3, Topic 12 Message 78 Mon Nov 27, 1989 A.HAMILTON1 [Alan H.] at 21:19 MST Yep, it's possible. Menu_register does not make a copy of the menu name; it only keeps a pointer to the name that's in your code. By changing what the pointer you passed to menu_register() points to, you can change the Desk menu title. The following code is an accessory that changes its name every time you select it. #include <aesbind.h> char name1[] = " Original name"; char name2[] = " New name"; main() { extern int gl_apid; char namebuffer[32]; int msgbuffer[8]; int toggle = 0; appl_init(); strcpy(namebuffer, name1); menu_register(gl_apid, namebuffer); for (;;) { /* For-ever */ evnt_mesag(msgbuffer); strcpy(namebuffer, (toggle != 0) ? name1 : name2); toggle ^= 1; } } / / * / Alan * * ------------ Category 3, Topic 12 Message 79 Tue Nov 28, 1989 CBARRON at 03:47 EST /* code to kill acc access from a gem menu given the menu address and index of the about... item. */ void kill_accs(menu_ptr,aboutidx)long menu_ptr;int aboutidx; { int k; for(k=aboutidx+2;k<aboutidx+8;k++) menu_ienable(menu_ptr,k,0); } ------------ Category 3, Topic 12 Message 80 Tue Nov 28, 1989 E.ROSENQUIST [Strata] at 12:30 EST Right-on Alan. I've been using this 'trick' for a while now with no adverse effects. One thing to keep in mind though: this is the sort of thing that could quite easily stop working in a future revision of GEM, since GEM might switch to copying the string rather than just hanging on to the pointer. You should also make sure to keep the entry <= 20 characters since that's the limit mentioned in GEM docs and enforced by some (but not all) resource editors. Eric ------------ Category 3, Topic 12 Message 81 Tue Nov 28, 1989 C.DAYMON at 19:15 EST Thanks, I'll capture this and save it away. -Craig W. Daymon ------------ Category 3, Topic 12 Message 82 Tue Nov 28, 1989 DOUG.W at 23:26 EST Hmm, if I remember right, I just disabled the "dummy" ACC entries in my menu resource in the resource editor. I suppose you could also "unlink" the ACC entries from the object and shorten the menu so that they don't show at all. --Doug ------------ Category 3, Topic 12 Message 83 Wed Nov 29, 1989 GRIBNIF at 18:57 EST Vewwy intawesting. I'll keep this in mind. So, does menu_bar() handle all the pointer changes in the resource tree so that the ob_spec's for the strings point to the correct location? This would seem to be the case, because I remember doing some tests and I found that the length of the string in the resource file (contrary to waht Eric said) did not matter. Methinks I will play with this a bit. Dan ------------ Category 3, Topic 12 Message 84 Wed Nov 29, 1989 C.DAYMON at 20:15 EST Thanks Doug, I hadn't thought that using the resource editor that way would affect the accessories. That seems like the safest way. Then there should be no reason to restore the tree on exit. -CWD ------------ Category 3, Topic 12 Message 85 Wed Nov 29, 1989 L.WEINHEIMER at 20:04 PST Thanks Alan! ------------ Category 3, Topic 12 Message 86 Thu Nov 30, 1989 E.ROSENQUIST [Strata] at 10:28 EST Dan - it's not so much the length of the accessory title string, but rather the width of the drop down box itself. AES doesn't seem to adjust this at run time - it just leaves it at the width that the author created via the resource editor. Resource editors like RCS 2 don't let you change the width, hence the need to stick to 20 characters if you wan't to play well with other applications. Eric ------------ Category 3, Topic 12 Message 87 Sat Dec 02, 1989 A.CUMMINGS [Big Al] at 12:41 PST I am looking for some info on forcing a Media detect update. We are pulling out our already thinning hair trying to clean up Cheetah. Also we put in a cold boot and we lose the keyboard. GEM we love it!! ------------ Category 3, Topic 12 Message 88 Sat Dec 02, 1989 GRIBNIF at 20:01 EST Eric, Ah, yes, I had forgotten about that. And, yes, apparently it is the menu_bar function that changes the pointers of the menu strings for desk accessories so that they point to the strings within the DA's code. This means that as long as you keep the outer box large enough, you can save a few bytes in the resource by replacing all those fake menu entries for DA's with empty strings. Al, Are you a registered developer? Did you get the TOS 1.4 notes? They have a very good example on how to force media change. Beware, though, I have discovered that under certain circumstances even Atari's own method can cause a very bad crash due to the bugs in the way open folders are handled in TOS 1.0 and 1.2. Dan ------------ Category 3, Topic 12 Message 90 Sun Dec 03, 1989 ORION.MICRO at 13:19 EST Al, You should be able to force a media-change status by simply doing a Rwabs() call with a buffer address of 0. For example, Rwabs (1, 0L, 0, 0, 2) should set the media-change status on drive C: (I'm not sure about the first argument -- can't remember if it should be 0 or 1). Keith ------------ Category 3, Topic 12 Message 91 Sun Dec 03, 1989 DOUG.W at 17:30 EST This is (I believe) officially undocumented and hard disk drivers are not require to support this. It should work fine on floppies, though. --Doug ------------ Category 3, Topic 12 Message 92 Mon Dec 04, 1989 JLS [John STanley] at 05:05 CST There's a program from Moshe Braner called UPROOT that does a media-change on any drive. I'm not sure if it's in the library, but if it's not, let me know and I'll upload it. It includes source code in assembly... ------------ Category 3, Topic 12 Message 93 Mon Dec 04, 1989 GRIBNIF at 14:37 EST Yup, I just dug-out my source to UPROOT. It does the same thing that is suggested in the Atari docs. Dan ------------ Category 3, Topic 12 Message 94 Mon Dec 04, 1989 JLS [John STanley] at 19:32 CST Are you sure Dan? I haven't looked at it in over a year, but I thought Moshe had used a slightly more elaborate trick to flush even floppy cache programs that don't know about the special parameter call to set media change... ------------ Category 3, Topic 12 Message 95 Mon Dec 04, 1989 DOUG.W at 22:04 EST John, the "official" Atari method doesn't depend on the RWABS trick, and works with any drive. --Doug ------------ Category 3, Topic 12 Message 96 Mon Dec 04, 1989 L.WEINHEIMER at 21:09 PST I have two questions: The first has to do with a "Bug" that Tom Hudson pointed out way back with the appl_find() call. After a program is terminated and the ST is returned to the DESKTOP the old program can still be found with this call. I have a desk accessory that I want to work while a specific program is called. If I use AC_CLOSE to detect the end of the DESKTOP, and use appl_find(), fine, but then the program cycles through the routine detecting a AC_CLOSE at the end of the program, and the appl_find says the program is still there. Has anyone found a way around this bug? Next, this same program I have been working on, developing as a program, then converting to an accessory. When I add the code, and execute as an accessory, the windowing PAGE UP, PAGE DOWN (clickins inside the grey slider area) produces two messages. This doesn't happen when the program is a program -- it also doesn't happen when the program erroneously executes from the DESKTOP. Thanks in Advance -- Larry ------------ Category 3, Topic 12 Message 97 Tue Dec 05, 1989 GRIBNIF at 19:15 EST John, ditto what Doug said. Larry, Personally, I wouldn't depend on appl_find() working for an application in the first place. Especially when you consider that if the user calls the application from inside a shell other than the GEM desktop the buffer that appl_find checks is not updated (unless the shell uses shel_write). Is the program (not the ACC) something you wrote? If so, I would suggest you try having IT use appl_find to look for the desk accessory, instead of vice-versa. Dan ------------ Category 3, Topic 12 Message 98 Tue Dec 05, 1989 JLS [John STanley] at 23:43 CST Dan and Doug. Ok guys, sorry about that. The last time this question came up online, someone at Atari suggested using the RWABS trick so I had assumed that was the "officialy sanctioned" method. (I'be been too busy for the last 4 months to even take the time to do a detailed read of the 1.4 docs... <sigh> ) Thanks for the correction. ------------ Category 3, Topic 12 Message 99 Tue Dec 05, 1989 L.WEINHEIMER at 22:39 PST Dan: Sorry, the program that I am writing the Accessory for is a comercial product (not mine). Larry ------------ Category 3, Topic 12 Message 100 Fri Dec 08, 1989 C.HARVEY at 20:12 EST Is there possibly an "easy" way to allow window slider scrolling ? I understand TOS 1.4 has this built in, but it seems that there should be a way to have sliders continue to slide by holding down the mouse button on the earlier TOS's. I figure when you do a window_create call, TOS/GEM must (?) create the objects somewhere in memory just as if you programmed in all the window pieces as resource objects. This would mean that there's a "Touch Exit" bit associated with the arrow buttons and if that bit were set, the arrow button would repeat with the mouse button depressed. Am I nuts? Is this already an old/proven idea? or should I start figuring out how to find that little BIT? ------------ Category 3, Topic 12 Message 101 Sat Dec 09, 1989 DOUG.W at 02:11 EST Interesting idea... I don't think anyone has discussed how windows are represented internally. --Doug ------------ Category 3, Topic 12 Message 102 Sat Dec 09, 1989 TOWNS at 03:53 EST This is a nice idea, but there are applications that depend on the way it works now. This is something that the application should take care of. For example, if you hold down the Left Mouse Button on a window "arrow" in DeskSet II, it will continue to scroll until the end of the window. To install code in the OS that would make it continue automatically would probably break DeskSet II and other applications. I think the solution would be to write an application library that handles this for you. Most of the commercial software developers usually write their own interfaces that sit on top of the AES. Remember that the AES is nothing more than a set of User Interface tools. How you take advantage of them is your choice. This is obvious from the fact that there are good user interfaces and bad ones :-) -- John ------------ Category 3, Topic 12 Message 103 Sun Dec 10, 1989 J.ALLEN27 at 02:17 EST The mechanism Deskset uses would determine if it would break or not. Does Deskset do this on TOS 1.0,1.2? Wouldn't this be breaking the rules? And most important...how many people will ever have DesksetII? ------------ Category 3, Topic 12 Message 104 Sun Dec 10, 1989 DARLAH [RT~SYSOP] at 14:52 EST Jim: I hear that the laser/dtp bundling deal is coming in with DeskSet. You may see people with this product due to that fact. Whether they stick with it might be another thing. I was not impressed and perhaps it will be another dust collecter. Time will tell.......now won't it. ------------ Category 3, Topic 12 Message 105 Sun Dec 10, 1989 C.HARVEY at 20:24 EST I don't think the idea I had in mind could possibly affect any program other than the one doing it. I'm not talking about redirecting any interrupt vectors or anything. I guess my question is simply, does GEM deal with window pieces (namely arrow buttons) created from the built-in functions the same as if the programmer created them as AES objects. ------------ Category 3, Topic 12 Message 106 Wed Dec 20, 1989 J.MCCRACKEN at 18:21 PST Does anyone know if there is a way to hide a folder temporarily. I am having some friends over to play with the computer, and there are certain folders I would rather not have them see. Thanks in advance for your help. John ------------ Category 3, Topic 12 Message 107 Wed Dec 20, 1989 JLS [John STanley] at 22:56 CST That's not a GEM question John, so I suspect the topic politzi will be moving your question soon, but... Assuming the folders you want to hide are in the root directory you can temporarily hide them using a sector editor. If you change the first character in the root directory entry describing a folder into an ascii 229 (hex E5) character, gemdos will think it's been deleted, but the sectors used will still be marked in-use so you can later recover the folder by changing the 229 back into whatever character you had there before. BTW, because gemdos does cache some of the directory info, you should hide or restore the directorys using the sector editor, save the changes, exit the editor, and then reboot your machine to make sure gemdos recognises the changes both times. BTW2, You can easily screw-up your disk using a sector editor if you edit things other than the folder names without knowing what you are doing. I therefore take no responibility for any damage you may do to your directory information if you don't make the right changes. I just know what I told you does work because I've occasionaly had relatives over myself... If you need a good sector editor, Memfile (in the library here on GEnie) works well... ------------ Category 3, Topic 12 Message 108 Thu Dec 21, 1989 ISD2 [Julius] at 21:49 EST Changing the first character of the folder name is dangerous. What if a new folder is created or a file is created? GEMDOS will look for empty slots with E5 in them. Zowie...yer folder really disappeared. Best way I've found is to keep 'goodies' on the last partition and just remove that icon and save the desktop. ------------ Category 3, Topic 12 Message 109 Thu Dec 21, 1989 C.F.JOHNSON at 19:50 PST Yep, Julius....I agree. Just remove the icon for the drive that contains the "sensitive" files from the DESKTOP.INF file. (Of course, this may involve some reorganizing of the data on the drives in question...) - Charles ------------ Category 3, Topic 12 Message 110 Fri Dec 22, 1989 JJKENNEDY [RT*SysOp] at 01:27 EST If you use UIS, you might want to disable it also. UIS will show the partition with the icon present or not. --John ------------ Category 3, Topic 12 Message 111 Fri Dec 22, 1989 JLS [John STanley] at 00:39 CST Hmm.. Julius is right. I didn't use the drive in question to save anything to the root while the folders were "hidden" so I didn't run into that problem. Sorry, I should have mentioned this. . . Julius, thanks for the 'save'... And JJKennedy is correct that just removing the icons isn't a solution if you use any programs that use the gem file-selector and you have UIS, Little- Green Selector, or tos 1.4 installed... Humma... Looks like it's time to write a folder-hideing prg..? ------------ Category 3, Topic 12 Message 112 Fri Dec 22, 1989 J.EIDSVOOG1 at 17:56 PST All this talk got me curious so I used a disk editor to set one of my folders to 'hidden' (kids, don't try this at home). Voila, it disappeared but will not be destroyed by writing new files to the disk. Of course, MaxiFile will show it if you use 'SHOW HIDDEN FILES', and you can still open it and use it. For the brave, simply change the attribute byte (the byte after the folder name) from a $10 to a $12, but don't blame me for any misuse of this information. John ------------ Category 3, Topic 12 Message 113 Fri Dec 22, 1989 J.HARRIS32 at 18:52 PST I am trying to get both mouse and keyboard input at the same time, but having intermittant results. I am using the AES call graf_mkstate to get the mouse position and button status. Then, if there are no mouse buttons pressed, I use the GEMDOS call Cconis ($0b) to check for key presses. The process repeats until there is either mouse button or keyboard input. The problem I am having, is that key presses are occasionally skipped. I hear the audible keyclick sound from the monitor, but the program does not detect the key press. (Happens approx 1 out of 5 times). What is causing the missed keys? Is there a better way to get the inputs I need? Thanks - John Harris ------------ Category 3, Topic 12 Message 114 Fri Dec 22, 1989 ISD2 [Julius] at 23:07 EST You can't mix GEM AES and GEMDOS calls... Any problem using evnt_multi()? Ask for mouse and keyboard events then use graf_mkstate() right after the evnt_multi() call to get the ALT, CTRL, and SHIFT key states... ------------ Category 3, Topic 12 Message 115 Sat Dec 23, 1989 TOWNS at 00:46 EST Julius is right. You should use Evnt_multi() to handle the inputs. Why poll something you don't have to? Let the AES do it for you! That's what it's there for! :-) -- John ------------ Category 3, Topic 12 Message 116 Sun Dec 24, 1989 J.HARRIS32 at 01:05 PST Charles, this is what I know so far about the LZH header. Byte Offset Contents ------ -------- 0-1 The first two bytes are a mystery still. 2-6 5 bytes ASCII, either '-lh0-' or '-lh1-' identifying whether compression is off (i.e. stored file), or on. 7-$a Size of compressed data, byte reversed format. (Low byte first) (P.S. It's wonderful converting from Intel processors isn't it...) $b- $e Size of original data, low byte first. $f-$14 Must be the Date-Time info, but I haven't checked the format yet. $15 Size of the filename. $16- xx Filename, up to the length specified in $15. No padded spaces. The file's CRC value comes right after the filename, followed by the compressed data. Each file in the archive has this header+data format. There is nothing special at the front, and each segment simply follows the previous one. That should be enough, and if you have any questions, let me know. John ------------ Category 3, Topic 12 Message 117 Sun Dec 24, 1989 C.F.JOHNSON at 09:46 PST Thanks, John. Unfortunately, GEnie's editor managed to make hash out of your message, but I think I can decipher what I need to know. - Charles ------------ Category 3, Topic 12 Message 118 Sun Dec 24, 1989 J.HARRIS32 at 23:50 PST Thank you for the quick responses. I don't think evnt_multi will work in my application. I have put up a screen full of filenames, and when you click and drag the mouse, it selects files as the mouse is passing over them. All I was checking the keyboard for, was the Return key to work with the default button object. If I could poll the mouse buttons and the keyboard at the same time, then after detecting a button press I could use graf_mkstate the whole time the button was held, to do all the file selecting. The main reason I didn't want to use evnt_multi to do the initial detection, is because of the delay between when you press the button, and when the AES gives you the message. If the mouse is being moved during that time, the starting point is missed. I realize this has been improved in the 1.4 ROMs, but there are still a lot of non-upgraded machines. The graf_mkstate call is fast enough so that no matter how fast the mouse is moved, no files get skipped. The bottom line, I'd like to have the Return key feature, but I don't want to compromise any performance to get it. Is there another way to grab the mouse button and keyboard state? Can you check the hardware without interference? John Harris ------------ Category 3, Topic 12 Message 119 Mon Dec 25, 1989 A.HAMILTON1 [Alan H.] at 07:19 MST You can get the information returned by graf_mkstate() by reading some of the line A variables. Call linea0() and use what's returned in D0 as the base for the following offsets: -602 Mouse x position -600 Mouse y position -596 Mouse buttons (bit 0 = right button, bit 1 = left) I think if you read these variables directly, you can use the BIOS routines to read the keyboard. Since you won't be calling GEM, it won't get a chance to "eat" keystrokes. / / * / Alan * * ------------ Category 3, Topic 12 Message 120 Mon Dec 25, 1989 J.HARRIS32 at 15:27 PST Thank you Alan, it worked great. I still had the old line-a document. You know, the one that taunts you about all the things that are supposed to be described *below*... I'll have to get the salad file again. (Lost it in a system crash before I got a chance to read it). It probably contains answers to lots of other questions as well. John ------------ Category 3, Topic 12 Message 121 Tue Dec 26, 1989 J.EIDSVOOG1 at 18:10 PST But if you read the mouse directly, you'll have to try and figure out how to eliminate mouse button 'fall-through' when you quit your program, bring up a file selector or an alert box. Fun stuff. ------------ Category 3, Topic 12 Message 122 Tue Dec 26, 1989 J.HARRIS32 at 23:08 PST Thanks Alan, it worked great. I still had the old line-a document. You know, the one that taunts you about all the things that are supposed to be described *below*... I'll have to get the salad file again. (Lost it in a system crash before I got a chance to read it). It probably contains answers to lots of other questions as well. And thank you John for the warning. Fortunately, I end up in a dialog box before exiting. John Harris ------------ Category 3, Topic 12 Message 123 Sun Dec 31, 1989 J.HARRIS32 at 15:39 PST Is there a way to tell the difference between whether an application was called from a command line, or called by double-clicking with an installed application? (Where the filename is put in the command line buffer). Thanks - John ------------ Category 3, Topic 12 Message 124 Tue Jan 02, 1990 J.HARRIS32 at 19:34 PST Charles, I still need to rephrase my command line question. Does GEM give any special identifiers to let you know that your program was called as an installed application? In other words, when your program is called as an application, it has the filename that was 'clicked on' in the command line buffer. If you type 'UNLZH FILE' from a CLI, you will also have the file- name in the input buffer. I want to be able to distiguish between those two events, as the program needs to respond differently in each situation. My earlier comment about the spaces was related to this task. The filename from an application call always starts in the first character of the buffer. I was wondering if the data from a command line call would start with the 'space' character in between UNLZH and the Filename. If that were true, it would be a way to distinguish command lines from application calls. I suspect though, some CLI's probably remove the leading space or spaces. If they did, the command line buffer would look identical to an application call. That's the problem. I want to know how the program was called. Is there a way to find out? Thanks. John ------------ Category 3, Topic 12 Message 125 Tue Jan 02, 1990 DOUG.W at 23:33 EST On the ST, the "command line" passed to an application is actually a "command tail" and doesn't contain the name of the application itself. --Doug ------------ Category 3, Topic 12 Message 126 Tue Jan 02, 1990 C.F.JOHNSON at 22:05 PST John, OK, I think I understand what you're asking. Unfortunately, the answer is probably "no". I don't think there's any way to tell if a command line has been set up by 'Install Application', or typed into a CLI. In either case, the first byte in the command line buffer (at the basepage+129 ... basepage+128 has the length of the command line) will be the first byte of the filename. To make things even worse, you should also be prepared to handle the command line whether it has a full pathname (e.g. C:\UTILITY\LZH\STUFF.LZH), or whether it just has the filename alone (e.g. STUFF.LZH). - Charles ------------ Category 3, Topic 12 Message 127 Wed Jan 03, 1990 JLS [John STanley] at 01:17 CST John, mind telling me why you need to handle it differently? Seems to me that it's important to have it work the same no matter which way you call the program with a parameter... If you can give a better explanation of why you think you need to recognise the difference, perhaps one of us can suggest an alternate method of accomplishing the same type of operation... ------------ Category 3, Topic 12 Message 128 Wed Jan 03, 1990 TOWNS at 02:44 EST I think there is a way to see if you are being run from the desktop or from a shell. I think you can look into the BasePage for information like this. I am just guessing and may be totally wrong, but I will ask around and see what I can find out. -- John ------------ Category 3, Topic 12 Message 129 Wed Jan 03, 1990 J.HARRIS32 at 03:21 PST The situation is in the UNLZH program. When called from a CLI, it needs to bypass the GEM dialog box, and go straight to extraction. When you double-click an LZH file from the desktop, it puts up the dialog box so you can select the different functions. This is not inconsistant. Running an installed application is a mouse/GEM operation. Typing into a CLI is not. It's the difference between running the program in GEM mode or TOS mode. It should respond differently. What I have done in 1.2 is to make you have to type something in front of the filename. Like an 'X' as in ARC.TTP. It will then search past it for the filename. It grabs full paths, like 1.1 was supposed to do also, but alas, didn't. John Harris ------------ Category 3, Topic 12 Message 130 Wed Jan 03, 1990 TOWNS at 12:22 EST You could account for each situation like this: 1. Check for a command line. If there is a 'FULL' command line with our options present, then excute the program as a TOS program (as if you were being run from a shell..) 2. If you have a command line WITHOUT your options and it just contains the .LZH filename that was passed as an installed application, then you run the program as a GEM program and get the options from the user. 3. If you don't have a command line, then run as a normal GEM program. 4. If you have a command line that doesn't look like that of your normal command line or that of an Installed Application, then print a usage message. I hope this helps. -- John ------------ Category 3, Topic 12 Message 131 Wed Jan 03, 1990 J.HARRIS32 at 23:34 PST Thanks John, This is basically the approach I used in 1.2, although the program does not actually do anything with command line options. It just uses them to put UNLZH in TOS mode. ------------ Category 3, Topic 12 Message 132 Thu Jan 04, 1990 J.HARRIS32 at 00:04 PST I have a question regarding the new FSEL routine that allows a title string. If you make the call on a machine that doesn't support it, do you get an error back in INT_OUT? Or do you need to determine that the routine doesn't exist beforehand, and call the older one to start with? John. ------------ Category 3, Topic 12 Message 133 Thu Jan 04, 1990 C.F.JOHNSON at 09:50 PST John, If you make a call to fsel_exinput with a version of TOS that doesn't support it, you get a "Bad Function Number" alert box. You'll have to first determine which version of TOS you're living with, then call fsel_exinput only if the version is greater than or equal to $104. - Charles ------------ Category 3, Topic 12 Message 134 Fri Jan 05, 1990 JLS [John STanley] at 04:13 CST Towns is correct. (Except when running ram-TOS) You can normaly figure out if you're being run from the desktop by tracing back the parent-basepage pointers and figuring out how "deep" you are. On the other hand, I think I'd prefer to have the command line arguments (or lack thereof) control the TTP/PRG operations since I, for one, would like to be able to us unlzh in full GEM mode while still running it from a cli interface. As an alternative, you could check the M_HID_CT variable in the a-line negative offset area to see if the mouse is active or not and use that to determine if you want to allow gem access or if you should just use the command line arguments to extract the file double clicked from the desktop (the mode I'd probably install). This way if the user wants GEM control over the extraction, he/she could install unlzh as a .PRG and if he/she just wants it to extract, install it as a TOS application... Now that I think of it, this (along with John's ideas) sounds like the best alternative. ------------ Category 3, Topic 12 Message 135 Sat Jan 06, 1990 J.HARRIS32 at 21:36 PST That's a shame about the 'Bad Function', because I would guess that there are no ways to determine if a user has older ROMs, but is using one of the after market file selector programs that support that feature. I suppose I will end up making it configurable. ------------ Category 3, Topic 12 Message 136 Sun Jan 07, 1990 ISD2 [Julius] at 11:14 EST But there is a way to determine which version of TOS is in the machine! ------------ Category 3, Topic 12 Message 137 Sun Jan 07, 1990 C.F.JOHNSON at 09:45 PST Julius, I think John's point was that there's no way to tell if a user has a version of TOS that doesn't support fsel_exinput, BUT also has installed an alternate item selector that does. (Which is true.) - Charles ------------ Category 3, Topic 12 Message 138 Sun Jan 07, 1990 M.EASTER [Mike] at 12:48 PST Charles - re old TOS plus newer selectors Does your old STart selector support fsel_exinput? (The reason I ask is because I'm using the STart selector with TOS 1.0.) I like the STart selector because it is "smaller" and simpler. What kind of problems can I have with such a combination? ------------ Category 3, Topic 12 Message 139 Sun Jan 07, 1990 DOUG.W at 15:53 EST Can't you just call fsel_exinput and if it returns a "Bad Function" error, call fsel_input instead? --Doug ------------ Category 3, Topic 12 Message 140 Sun Jan 07, 1990 C.F.JOHNSON at 13:46 PST Mike, No, the Start Selector does not support fsel_exinput. Doug, Unfortunately, the system puts up an alert box on a "Bad Function Number" error, instead of just returning a code. (I don't think it would make the right impression if people had to click through that error alert every time they used the file selector...) - Charles ------------ Category 3, Topic 12 Message 141 Sun Jan 07, 1990 ISD2 [Julius] at 17:11 EST Gee Charles...you did have to complicate things, didn't you? <grin> ------------ Category 3, Topic 12 Message 142 Sun Jan 07, 1990 E.ROSENQUIST [Strata] at 21:22 EST I don't suppose this is the proper place to post this, but since we're on the subject.... Charles: I was experimenting the other night & added code to put the LGSELECT compatible prompt strings in my fsel_input() calls. Just for fun I thought I'd try the similar trick for fsel_exinput(), ie. increase the count for addr_in by two and pass two more strings. No luck. Is this supposed to work, and if not, could you make it work please? Considering that you already handle the extra strings for fsel_input() calls I can't imagine it being all that horrendous.... but then again, I didn't write it so I have no way of knowing. Eric ------------ Category 3, Topic 12 Message 143 Mon Jan 08, 1990 DOUG.W at 01:21 EST Charles, any change LGS could put add a cookie for other programs to look for? --Doug ------------ Category 3, Topic 12 Message 144 Sun Jan 07, 1990 C.F.JOHNSON at 23:13 PST Eric, Hmmm....so you're saying that you passed fsel_exinput an addrin count of 5, and put the title strings for LGSELECT in addrin[3] and addrin [4]? Well, that definitely ain't gonna work with LGSELECT the way it is right now. But that might be a good idea for a future update...thanks for the suggestion. Doug, Since we've been talking about this here, I've decided that I will add some method for other programs to determine if LGSELECT is installed. I haven't decided on a method to use yet, however; it will probably either be through the Cookie Jar or through an undefined BIOS call. (The undefined BIOS call is a _lot_ less work than properly setting up the Cookie Jar...) - Charles ------------ Category 3, Topic 12 Message 145 Sat Jan 27, 1990 C.DAYMON at 17:21 EST Hmm... I'm a bit confused by this conversation about fsel_exinput(). I thought the function call was supposed to work on any version of TOS. I has the impression that fsel_input() would just ignore the extra parameter. Now I'm a C programmer and not exactly sure what happens in assembly when the call is made, but I thought that when a function is called in C, the parameters are placed on the stack and a function (unless it wants the incoming parameters to be 'register') would simply address locations on the stack to use the parameters. Throw a couple of extra parameters on the stack and they should be ignored by the called function because it has no provisions to address that far back on the stack. On a return, the stack pointer is reset to the location it was on before the call and all is fine. If the additional string pointer is the last parameter on the stack, it should never be seen by fsel_input(), but will be there to be used by fsel_exinput(). Copying input parameters to local variable space seems wasteful since this is just stack space in a C program anyway. (Again, unless it is designated static or register.) Wait a second, maybe I should completely digest the information presented first. I think what I said above is correct, but the problem is not the number of passed parameters, but the function number actually called. I guess ideally fsel_exinput() would ALWAYS be called by new ROMs for either fsel_input() or fsel_exinput() and if the extra parameter is present, (fsel_exinput() was called) the string would be displayed. Otherwise, it would be the same as calling fsel_input(). What I mean is that fsel_exinput() and fsel_input() would have the SAME function number but new ROMs would check for the extra parameter. (?) -Craig W. Daymon P.S. I always ramble like this when trying to figure a problem. Sorry. ------------ Category 3, Topic 12 Message 146 Sat Jan 27, 1990 GRIBNIF at 20:22 EST fsel_input() and fsel_exinput() have different AES function numbers. If you call fsel_exinput() on a machine that doesn't support it you get an "Invalid function #" error alert on your screen. There ain't no way around it other than to look at the ROM version and decide which call to make. Of course, UIS and LGSELECT most likely support either regardless of TOS version, but you can't expect everyone to be using one of these, now can you? <smile> Whoever added the call for fsel_exinput() into the 1.4 ROMs probably could have made it work according to the number of parameters in the addrin array, but I guess he didn't think of that. Oh well. Dan ------------ Category 3, Topic 12 Message 147 Sun Feb 04, 1990 JLS [John STanley] at 01:05 CST UIS-II doesn't support fsel_exinput because it didn't exist (I think) when UIS-II was written. I have no idea what UIS-III does or doesn't do since I don't have it yet... ------------ Category 3, Topic 12 Message 148 Fri Feb 09, 1990 J.HARRIS32 at 00:02 PST I am having a couple problems converting UNLZH to a desk accessory. First, is there a way to get GEM to redraw the entire screen when the DA exits? Right now, it's only redrawing the part occupied by the initial dialog box. I use the Line A variable to check mouse buttons during operation, and before going back to the main dialog box, I call EVNT_BUTTON to clear the button clicks from the AES. This worked fine in the program version, but it never returns in the DA version. What's going on? Thanks - John ------------ Category 3, Topic 12 Message 149 Sat Feb 10, 1990 GRIBNIF at 14:13 EST John, If you want to undraw the entire screen, you can either use use form_dial(FMD_FINISH... with a rectangle the size of the entire screen or you can have UNLZH open a window beforehand and then just close it when it is done. Why are you monitoring the mouse via the Line A variables? Why not use evnt_multi() like the rest of the world? The real purpose of evnt_button() is to wait for a button press, not to clear the AES' buffers. In either case, if your ACC needs to draw over the GEM menu bar, you will have to copy the menu bar into some place in memory before corrrupting it and then copy it back when you want the screen restored. There is no way to force the menu bar to redraw without knowing where its resource object tree is in memory. Dan ------------ Category 3, Topic 12 Message 150 Sat Feb 10, 1990 C.HARVEY at 15:16 EST Here's one for you ACC gurus: If I Alloc a block of ram at boot up (for my text editor's buffer), and then switch resolutions (lo <-> med) via the desktop Set Preferences, TOS does not Free up my block of memory. This means that when it reloads all the acc's in the new resolution, they go on top of that unfreed ram thus using up gobs of ram unneccessarily. I've gotten as far as being able to free it myself by watching for an AccClose notice in the GEM msg buffer, and although this works, it then also frees it anytime an application starts/stops, which leads to other problems. Acc's like MultiDesk apparently have a way to deal with this, so it must be possible. However, I know that any of the other text editor acc's besides my Diary also do NOT know how to deal with it. Anyone willing to divulge the secret?? ------------ Category 3, Topic 12 Message 151 Sat Feb 10, 1990 GRIBNIF at 15:43 EST Well, this whole thing has been discussed a lot in the past, but here goes again... When the GEM desktop changes resolutions it *should* release any memory allocated to the actual code of desk accessories (whether or not it does under all circumstances is still uncertain to me, since I've seen things like you describe happen also.) What I think may be happening in your situation, however, is that because the memory you Malloc() ends up belonging to the GEM desktop and not to your desk accessory, it is not freed when the desktop changes rez. This means that a "hole" in memory is created where your desk accessories were previously, up to where the Malloc'd memory block still is. When the desk accessories get loaded the second time, they are loaded at the place after the Malloc'd block, because that is the largest block of free memory. The idea of doing the Mfree() during AC_CLOSE is not very good at all, not only because you are de-allocating memory in an order which is not the reverse of the way it was allocated (which is a no-no under the broken memory mangling of TOS 1.0 and 1.2) but also because I really don't think GEM does send an AC_CLOSE when it is going to change resolutions. In any event, it's just not a good idea to allocate memory from a desk accessory when it is initializing because of things like STARTGEM and TOs 1.4's autobooting feature that will cause the memory to belong to the wrong process if you do. What I would suggest is a configuration option for the buffer size that gets saved into the program itself. You can have the startup code for the desk accessory change its basepage so that GEM will know how much extra memory to reserve for the buffer. This way, when the user changes rez the whole thing automagically gets de-allocated. The disadvantage is that the buffer size cannot be changed without re-booting. I'm sure that someone else here can comment on what, specifically needs to be changed in the program to get GEM to reserve the extra memory. I think that just setting one of the segment sizes in the program header (like adding to the BSS) would be sufficient. Dan ------------ Category 3, Topic 12 Message 152 Sat Feb 10, 1990 J.HARRIS32 at 15:59 PST Dan, thanks for the FORM_DIAL answer. Worked great. Mouse input for the program has been discussed here before, and EVNT calls would not work for my application. I did find a way to clear the extra mouse clicks however. I cleared bits 6 and 7 of the LineA variable CUR_MS_STAT, the flags indicating whether the buttons have changed. Is there anything wrong with doing this? John ------------ Category 3, Topic 12 Message 153 Sat Feb 10, 1990 C.F.JOHNSON at 18:20 PST C.Harvey, There is a way to detect when a resolution change is occurring, but it's necessary to intercept trap #1 to do it. Basically, the idea is to watch for an Mfree() call with the address of your basepage. The only time you should ever see this is right before the desktop changes resolution. When the Mfree() comes through, you do your own Mfrees for any memory blocks you've allocated, and then replace the trap #1 vector with whatever was there when you first grabbed it. There are some other big problems with allocating memory from a desk accessory, not least of which is that any Mallocs you do will be assigned to the current running application (NOT to your desk accessory), and if the user quits that application your memory will be freed. - Charles ------------ Category 3, Topic 12 Message 154 Sun Feb 11, 1990 C.HARVEY at 13:12 EST Ahh, some good info from both of you. From prior discussions on this stuff I was aware of the problems of allocating memory AFTER bootup such as from within a running application, which is why I was going to only do it at bootup. I was not aware of the problems with Freeing it myself however. Since I am willing to have it only changeable with a reboot, it sounds like Dan's idea of modifying the basepage is a good approach. Besides, I now know a _little_ about what a basepage is, but all I know of stealing traps is from overhearing it here. By the way, on the ACC Close message on a res change, it does definitely happen, and if your window is open, it is preceded by a Redraw message. (at least on my TOS 1.0 system). Thanks much! Craig ------------ Category 3, Topic 12 Message 155 Sun Feb 11, 1990 C.F.JOHNSON at 10:42 PST Craig, Yes, if your ACC's window is open, you do get an AC_CLOSE message on a res change. But it's fairly useless at that point, since if you're going to free up your Mallocs every time you get an AC_CLOSE message, you're in trouble already. I've heard that rumor about problems if you release Mallocs in anything other than the exact opposite order. It may have been true in TOS 1.0, but I've never seen any strange behavior like that in TOS 1.2...even when I tried to make it happen with MultiDesk. I used the technique of modifying the executable file header (_not_ the basepage) in the Macro Mouse accessory. It's quite simple; just change the "length of BSS" variable at 10 bytes into the header. (That's decimal 10.) You may also want to read your basepage during init to find out how big your BSS really is -- which presents another set of problems, since the only legal way to get the address of your basepage when you're running as an accessory is from register A0. (A0 points to your basepage when you're an accessory...when you're a program A0 is zero on startup.) - Charles ------------ Category 3, Topic 12 Message 156 Wed Feb 14, 1990 C.HARVEY at 23:50 EST Charles, thanks much for that info about A0. I'll have to give it a try although I've gotten around it by subtracting 1200 (dec) from where you would normally get the basepage address off the stack (i.e., get the address off the stack and then subtract 1200). For whatever reason, this actually seems to work fine. And yes, modifying the bss length in the file header is working fine. I think my only remaining problem is getting the filename in case it's been changed from the name I give it (e.g., if it's being run under MultiDesk as 'diary18.acx'). I had thought I could get that from the 'command line image' at byte 128 of the base page, but it doesn't seem to be there. I can get the drive and path ok, but what about the filename?? Craig ------------ Category 3, Topic 12 Message 157 Mon Feb 19, 1990 C.HARVEY at 16:29 EST A couple things... first, a little more info on finding the basepage of a DA: I tried reading A0 and using it as a pointer to the basepage, which didn't work. One obvious suggestion that hadn't occurred to me is to just take 256 off the program counter at the start of the program (Darek Mihocka pointed that one out to me). Next question: Is there a way to find out if a given window is open (and thus able to be Topped)? It seems that Flash closes my DIARY window when going to on-line mode, but the message sent is an identical redraw message to what the desktop sends when moving a directory window over my window (without closing it). The trouble comes when returning to Flash's edit mode and trying to get my Diary window back. If I just try to Top it, everything locks up, but if I re-Open it, it's fine. But I can't just always re-open, since if I'm not in Flash, it's trying to open an open window which screws things up. And there is no error code returned from either the window open call or the window top call when they screw up as above. [I have Compute's AES book on order, which may shed some light on all this...] ------------ Category 3, Topic 12 Message 158 Mon Feb 19, 1990 C.F.JOHNSON at 17:22 PST Craig, All I can tell you is that I've converted all my program/accessories over to use the A0 method to find their basepage, and it seems to work fine. Aren't you using Pascal? If so, the Pascal startup code may be destroying A0 before you get a chance to examine it. (I don't know...just a guess.) Yes, you can just subtract 256 from the PC at the start of the program. That will probably work almost 100% of the time...but the hitch there is that the basepage is _not_ guaranteed to always be located 256 bytes before the start of your program code. This means that if you really want to stick to the book, you should try to make the A0 method work. - Charles ------------ Category 3, Topic 12 Message 159 Tue Feb 20, 1990 GRIBNIF at 19:58 EST As for the window stuff, if Flash truly is closing the window then it must be doing some pretty weird stuff. Are you sure it isn't just making another (invisible) window when you change modes? I've never heard of this behavior in Flash before, but I don't have a copy here so I can't test it. If Flash does close your window to the point where you can't set it with WF_TOP, Flash should definitely be fixed. This is not normal behavior for a GEM program. By the way, what happens if you open Atari's control panel, leave it open while switching to terminal mode, and then re-open the control panel from the dropdown? Does this crash also? If not, then you might be doing the wind_set() call incorrectly. Dan ------------ Category 3, Topic 12 Message 160 Tue Feb 20, 1990 FB [ST Librarian] at 20:27 EST Dan, Leaving the control panel on and switching to the terminal is usually a good way to crash. I don't know if it was ever fixed but it is one of those things you do one time and never again! Flash was in it early stages when I tried that and I just never really wanted to do it on newer versions. Fred ------------ Category 3, Topic 12 Message 161 Wed Feb 21, 1990 GRIBNIF at 19:57 EST Wow. Major nastiness. If I were writing a desk accessory I wouldn't bother trying to avoid this problem, since it sounds like the kind of thing that is "accepted behavior" from the program. You may want to mention it in the doc file though, so users won't be tempted to try it. Dan ------------ Category 3, Topic 12 Message 162 Sun Feb 25, 1990 C.HARVEY at 11:05 EST Charles, Chances are you are right about my Modula-2 startup stuff somehow destroying A0 before I can get to it. For now I'm just sticking to the weird way I found that works -- taking 1200 off the stack value. Dan & Fred, I found a way around the Flash problem (after reaching despair on it I read about my 'Honorable Mention' in the CPU Shareware Connection and got so revitalized that I came up with a workable solution. I'll just say that it involves checking the FirstXYWH as if you wanted to do a redraw, and using the result to determine whether to top or open the window. ------------ Category 3, Topic 12 Message 163 Sun Feb 25, 1990 C.HARVEY at 11:13 EST With all the progress I've made, Diary v 1.8 should be out very soon. However, one thing I'd like to add (maybe not til 1.9) is the ability to run as either an acc or a prg. Is there some easy way to tell what filename your program had when it was called? This would also let me save config things to the acc file even if it were run as acx through MultiDesk without asking the user to find the file -- as well as letting me know if it were run as a prg or not. A related question is: Is there a way to tell if your program was run as a prg or acc without checking the extender? I thought maybe the basepage's pointer to parent's basepage would tell me something, but it seems like that's always zero. Craig ------------ Category 3, Topic 12 Message 164 Sun Feb 25, 1990 C.F.JOHNSON at 08:53 PST Craig, Subtracting 1200 from the stack pointer?? Now that's an odd one...I can't imagine why that works, but my sincere advice is to find another method. You're asking for trouble down the line if you use a totally undocumented technique like that. There's really no way to find out your accessory's filename after it runs. (Some time ago, I chased that rabbit down a hole for quite a while.) However, if you assume that the user doesn't rename the file (and you can tell him not to, in your docs), it's easy to use Dgetdrv() and Dgetpath() at init time and build a full pathname...and this will work either as a normal accessory or loaded into MultiDesk. As for the prg/acc thing...the parent's basepage is indeed telling you something! When that pointer is zero, you're running as an accessory; when it's not zero, you're a program. Using this method to determine which way you're running is a pretty good second choice (instead of checking A0), but it has a potential pitfall. It requires you to assume that the basepage starts 256 bytes before the beginning of your code, which is not guaranteed unless your program was run from the desktop. (A shell program could conceivably use the different modes of Pexec to create a runnable program whose basepage is not 256 bytes prior to its TEXT segment.) - Charles ------------ Category 3, Topic 12 Message 165 Fri Mar 02, 1990 C.HARVEY at 20:17 EST Ahh well, I guess I'll have to resort to letting the user find the file since I DO want to allow users to rename the thing and thus be able to run multiple copies of it at once (I've found this very handy at times). Then again, I can leave it as it is, forcing the name to be one thing when reconfiguring the buffer size, but once the user has reconfigured it, he is free to rename it.... only mildly complicated. Thanks for all the help! Craig ------------ Category 3, Topic 12 Message 166 Sun Mar 04, 1990 R.FOSTER1 at 16:53 CST I need a question about GDOS answered. I have a program that I some time ago which copies a graphic image into a window as on. This has worked out just fine for a long time I have added GDOS to my system, the blit call doesn't cause to happen. If I take out GDOS(or G+PLUS), everything works . is a andle,3,xyarray,&sourcemfdb,&destmfdb); some sort of initialization that needs to be done with addition to the appl_init(), v_opnwrk(..),vs_clip(..) program doesn't use GDOS but something about GDOS being messing things up. Any GDOS tips appreciated. ------------ Category 3, Topic 12 Message 167 Sun Mar 04, 1990 C.DAYMON at 23:11 EST R.FOSTER1, Please repeat your last message. It was a bit garbled and I'm not sure what your asking. -Craig W. Daymo ------------ Category 3, Topic 12 Message 168 Mon Mar 05, 1990 E.ROSENQUIST [Strata] at 12:30 EST Check the work_in[] parameters to your v_opnvwk() call - you're probably specifying normalized device coords (NDC: 0 to 32767) rather than raster coords (RDC: 0 to screen-res). Without GDOS NDC coords don't exist and hence you get raster coords. With it you're blitting to/from a very tiny area. Eric ------------ Category 3, Topic 12 Message 169 Fri Mar 09, 1990 R.FOSTER1 at 21:22 CST This is a repost due to garbled first post. I am having a problem with using GDOS(or G+PLUS) which is really baffling me. I wrote a program some time ago that as part of it's operation needs to blit some images to the screen. This program has been working for some time but since I added GDOS to my system, the blit calls no longer work. Nothing at all happens. If I remove GDOS, everthing is fine again. I am speculating that there is something else I need to do with GDOS loaded that I don't know about. This is the program sequence. appl_init(); grhandle=graf_handle(...); v_opnvwk(in,&grhandle,out); whandle=wind_create(...); wind_open(whandle,...); ;;;/* Other stuff */ vro_cpyfm(whandle,3,....); /* Works fine without GDOS */ /* Does nothing with GDOS */ Thanks, Bob Foster ------------ Category 3, Topic 12 Message 170 Sat Mar 10, 1990 E.ROSENQUIST [Strata] at 13:41 EST You're using the window handle 'whandle' rather than the VDI workstation handle 'grhandle' in your vro_cpyfm() call. Without GDOS you may have been lucking out and having the same values in both. Eric ps: use *SN to save a message containing things like source code that you don't want GEnie to reformat. ------------ Category 3, Topic 12 Message 171 Sat Mar 10, 1990 JLS [John STanley] at 13:04 CST Good eyes Eric, I was trying to figure out what he was doing wrong and because of the reformatting, that line came out looking like a seperate comment. Bravo! ------------ Category 3, Topic 12 Message 173 Sat Mar 10, 1990 A.HAMILTON1 [Alan H.] at 13:24 MST In the vro_cpyfm(whandle,3,...) statement, you should replace whandle with grhandle. All the VDI commands use this. Only the wind_whatever() commands use the window handle. It may work without GDOS because it's probably assuming screen output without actually checking the handle. GDOS *does* check the handle, so that could be what's messing you up. / / * / Alan * * ------------ Category 3, Topic 12 Message 174 Tue Mar 13, 1990 M.L.HANSON at 18:26 CST What are the rules for displaying hidden files on the GEM desktop? They normally show. Today I _copied_ a hidden file, and the copy didn't show. Great! All I have to do is hide them, copy them, and delete the original. But I can't repeat the feat. I've got exactly one hidden file that's treated properly but I can't get another one. I've tried both the UIS copy and the GEM copy. No difference. ------------ Category 3, Topic 12 Message 175 Tue Mar 13, 1990 V.AVERELLO [Vince-Cubed] at 21:09 EST I think that if a file has the hidden attribute and one other attribute set (like read-only or archive) then the file WILL show on the desktop. If only the hidden attribute is set then the file WILL NOT show. This is something I think I read in one source or another. Vince - V-Cubed Software ------------ Category 3, Topic 12 Message 176 Wed Mar 14, 1990 GRIBNIF at 21:32 EST Yup, Vince is right. If any attribute besides hidden is set, then you will always see the file on the GEM desktop (but not in NeoDesk <plug>). Dan ------------ Category 3, Topic 12 Message 177 Thu Mar 15, 1990 C.DAYMON at 19:09 EST OK, Hears a problem I recently encountered that I don't understand. (I guess that's why I think it's a problem!) I have opened a window for displaying a graphics image (to allow clipping a section of the image) and I wanted the window to be as large as possible so the maximum amount of the image would be visible. So I created a window the size of the entire screen, not just the area below the menu. Now everything works OK except when I go to click on the "CLOSE" button to exit. The button inverts, indicating selection but I don't exit until I move the mouse below the area normally allotted for the menu. Any clues why this happens? This is on a Mega 4 with TOS 1.4. The code is written in Laser C. Creating the window the size of the area below where the menu would be results in everything working as expected. -Craig W. Daymon P.S. One more thing, closing a window that fills the entire screen does not result in the entire screen being redrawn. The window Title bar remains at the top of the screen. ------------ Category 3, Topic 12 Message 178 Thu Mar 15, 1990 C.F.JOHNSON at 16:57 PST Craig, That happens because the area at the top of the screen is reserved for use by the GEM Event Manager. You can see this behavior in lots of programs; take any program that uses a menu bar and evnt_multi to get keyboard input. If you move the mouse into the top line (the menu bar line) and hit a key, the Event Manager will not send the MU_KEYBD message along to the application until you move the mouse back into the desktop's "work area". The top area doesn't get redrawn either, because that area is outside the "work area" of the desktop's window. (Window zero.) There's really no way to do what you're trying to do, and still use standard GEM calls. (Which is why you haven't seen any ST programs with *real* full- screen windows before...) - Charles ------------ Category 3, Topic 12 Message 179 Fri Mar 16, 1990 D.S.HARRISON at 18:51 CST If you did a wind_update(BEG_MCTRL), then the event manager would treat the menu bar area like the rest of the screen. Unfortunately, your window controls in that area would cease to function, at least through GEM. Does anyone know of a possible bug in GEM related to non-detection of mouse-up events, until the mouse is moved? I'm noticing that in a program, and I've also seen it in the GEM Desktop, where sometimes if you click on the desktop background and the rubber rectangle appears, you can release the mouse button, without moving the mouse, and the rubber rectangle will remain until the mouse is moved. -Doug ------------ Category 3, Topic 12 Message 180 Fri Mar 16, 1990 C.DAYMON at 21:05 EST Doug, I think that problem has been corrected in newer versions of the OS, but I know it existed in version 1.0. Something to do with the mouse not returning information until the mouse is moved. Maybe the information is packeted so that motion returns the button state, but a change in button state doesn't generate a separate message. ANyway, I know of the problem, but forget the exact cause. Charles, Then it sounds to me like this is a bug in GEM. (Or Atari GEM.) I haven't enabled a menu or even drawn one on the screen and GEM should ONLY be responding to those possible states that I have activated. (Which is just a window with sliders and a CLOSE button.) I realize that there are still accessories active in the system, but again this should not matter since a menu must be available for an accessory to be activated. (Maybe the link to the display of the menu has not been properly established?) I can probably test and see if I get the same response if ALL accessories are removed. It's just annoying because I really wanted to maximize the window display. Thanks for the help. -Craig W. Daymon ------------ Category 3, Topic 12 Message 181 Fri Mar 16, 1990 D.S.HARRISON at 22:19 CST Craig, That's what I thought; it seems to be at a lower level than the AES, because sampling the Line-A variables doesn't help. About your menu bar problem: I found exactly the same thing you did, that is, it doesn't seem to matter whether a menu has been displayed or not. The only solution I found was the wind_update() call, but for your purposes, that's probably not acceptable (unless you feel like rolling your own window controls). -Doug ------------ Category 3, Topic 12 Message 182 Sat Mar 17, 1990 DOUG.W at 01:36 EST I think "GEM Law" states that all GEM applications will have a menu bar. --Doug ------------ Category 3, Topic 12 Message 183 Mon Mar 26, 1990 RHFACTOR at 01:30 EST Hello GEM Gurus, I'd like to post a question to you all, though this may not be a GEM one. I've been asking all around, hope maybe this might be the right place. When the ST is booted, call a couple of clicks on the Drive 'A' icon opens a window displaying the directory. AT the top of the window is displayed the number of bytes used in so-many-number of items. Question: Where in the ST is this information gotten from. Specifically, how does it know how many files are on disk. My predicament: how to tap into this info. I'm working with GFA 3.07, is there a peek or bios call that can be read that tells how many files are on disk. It seems pretty slack that I would have to read the DIR into an array, and increment a counter to make sure that my program does not try to save more than 112 files to a disk. I've have a disk that about 116 files where attempted to save, and the data turned to scrambled eggs. Any ideas or suggestion! Thanks! Ron ------------ Category 3, Topic 12 Message 184 Mon Mar 26, 1990 JLS [John STanley] at 03:21 CST Ron, there's no single call to get the number of files on a single disk. However, I feel compelled to point out that you're certanly not limited to 112 files per disk.... Just put your files into a folder and your folder directory will expand until you run out of space on-disk.. (for which a function call does exist (although it's slow unless you're using TOS 1.4 or a "diskfree" enhancement TSR program)). BTW, the info at the top of the window on the desktop is -not- the number of files-on-disk. It's the number of files in the directory currently being shown. Since subdirectories are allowed, you can have many other file areas (subdirectories) on the disk that aren't included in the "xxxx bytes in xx items" line in the window. BTW2, the info in the window line is determined by reading the directory, counting the files, and adding up the sizes of all the files. BTW3, your problem with writing "too many files" to the root directory of a disk is most likely caused by using a non-standard disk-formatter program that put bogus info into the structure table stored on-disk that the ST uses to figure out where to store stuff... What formatter did you use for that specific disk? BTW4, this whole line of discussion really has nothing to do with "GEM" questions and possibly should be moved into a new topic by Darlah or one of the other sysops... ------------ Category 3, Topic 12 Message 185 Sun Apr 01, 1990 V.BURTON4 at 15:27 MDT Hello, All, I just downloaded MONSTER.ARC, which emulates a moniterm monitor on any S ST with TOS 1.4 or newer. I would like to know how to tell GEM that you are working with a larger resolution, which apparently MONSTER does. This would be great for a GDOS program I'm working on! thanks! BTW, I'm using GFA 3.07 ------------ Category 3, Topic 12 Message 186 Tue Apr 03, 1990 GRIBNIF at 14:58 EDT In order to get the AES portion of GEM to use a new screen size, you have to change a few of the Line A variables that the system maintains. The only catch is that you have to do it *before* GEM initializes, which means it has to be done from a program that runs from the AUTO folder. This is not the kind of thing that is well-documented, and not for the faint of heart. If you'd like to experiment with it, however, you should have a look at one of the various documents on the "negative offset Line A variables", like the one called SALAD that is supplied with the developer kit from Atari. Dan ------------ Category 3, Topic 12 Message 187 Tue Apr 03, 1990 DOUG.W at 15:24 EDT Be sure to change ALL of the appropriate variables, or you'll get strange results. --Doug ------------ Category 3, Topic 12 Message 188 Wed Apr 04, 1990 V.BURTON4 at 18:58 MDT Thanks for the info! Another question, does anyone know of a PD Icon editor editor, I'm using the resource construction program that comes with AGFA Basic 3.07, and it says that Icon editors are available. cant seem to find one on GENIE, though. . . ------------ Category 3, Topic 12 Message 189 Sat Apr 07, 1990 BRIAN-G at 21:55 EDT Got a question on GFA and Gem. Even if you dont know GFA you may be able to answer so please read. Doing something similar to a file selector. Window type thing but will be client names. What kind of a dialog do you use. I need to single or double click on the client name as well as ok and canel buttons plus edit fields. Closet I come is touchext on the names but what about double click. If I call event_multi just after a form do and set button and timer, event multi ends immidately with a button event. (I do wait for the button to raise after touchexit). How do I clear the event from FORM_DO. And then I set the name as select and OBJC_DRAW but name doesnt redraw. I have to redraw the parent to. In GFA there is a Hybrid FORM_BUTTON. Cant get it to work even remotely. Also in windowing WIND_CALC doesnt return the right Height. It gets the other values right though. WIND_GET returns same values. Why have WIND_CALC when WIND_GET also perform similar functions. Jeez. Is that enough to complain about? Been saving them up trying to solve on own. Somebody please Brian Gantzler ------------ Category 3, Topic 12 Message 190 Thu Apr 12, 1990 J.HARRIS32 at 19:44 PDT How can you find the original memory size in cases where Ramdisks or other utilities have installed themselves at the top of memory and changed the pointers? Can $424 (memcntlr) be used for that purpose, and if so, what value does it contain for 2M, 4M, and higher? Thanks, John ------------ Category 3, Topic 12 Message 191 Fri Apr 13, 1990 B.MCCORKLE at 18:47 CDT I read an earlier message that referred to the line a call to M_HID_CT, that allowed access to the number of times the mouse was hidden. Can anyone give the offset of M_HID_CT? Thanks, Brian McCorkle ------------ Category 3, Topic 12 Message 192 Sat Apr 14, 1990 DOUG.W at 00:46 EDT Brian G., if you are looking for single or double-clicks, don't use form_do. Simply use form_draw to put the dialog on the screen then use evnt_button (or evnt_multi) to get the mouse clicks. When you get a click, see if it was a single- or double-click, and find out what object was under it (objc_find). --Doug ------------ Category 3, Topic 12 Message 193 Sat Apr 14, 1990 C.HARVEY at 09:57 EDT re: M_HID_CT -- It is a word located at offset -596 (-$254) in the LineA variable table. Compute's Atari ST vol 3 has all these goodies and much more. Craig ------------